Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Oracle Performance Tuning and Optimization
(Publisher: Macmillan Computer Publishing)
Author(s): Edward Whalen
ISBN: 067230886x
Publication Date: 04/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


What To Test in the RDBMS

You should test the RDBMS with functionality as well as load testing and performance in mind. Make sure that the system will function as specified with the required number of user connections. Usually, these connections do not have to be real users for the test, but you should make sure that you can invoke the application the same number of times as the required user load.

Many times, applications function properly with a few users connected but when a large number of users is connected, contention or other problems bring the system to a halt. You must test both the functionality and the performance of the application and the RDBMS.

Once you build a test load that stresses the system by simulating a large number of connected users, you can start looking at performance. Check both response times and throughput to verify that you can handle the required load. If you design a test that simulates the maximum number of users the system is required to handle, be sure to put simulated delays (for keying-in time and think time) into the test.

Real-world users vary in the amount of time they take to input data into the system because most input requires some sort of interaction. Once the data is displayed on the display device, users vary in the amount of time it takes them to view the data and think about it. Program some variation into the keying-in and think times so that all the users don’t work on exactly the same cycle.

Once you build an effective load test with repeatable performance results, start changing some of the parameters described in Part II of this book and that you have seen in this chapter. Change only one parameter at a time so that you can determine which changes affected performance and by how much.

Before changing anything, define your expectations for the changes you are going to make. If the results don’t turn out as expected, try to understand why they didn’t. Be sure that you log your results so that you have a reference of what changes were effective and what changes were not.

What To Test in the OS

For the most part, the OS is tested with the RDBMS. If you want to change some specific OS parameter that is needed to increase a limitation, you usually don’t have to retest the performance just for the OS change. Any limit change is usually associated with an RDBMS change, and the two can be tested together.

Other changes such as feature enhancements should also be tested with the RDBMS, but you should watch and analyze the results more closely. Things such as scheduler changes and cache affinity that may have an adverse effect should be analyzed very closely to verify that performance has not degraded.

The OS is primarily a vehicle for the RDBMS to use. The primary goal in tuning the server OS is to reduce overhead and optimize the I/O, memory, and networking subsystems.

Benchmarks

Standardized benchmarks are a good way to judge how well a system is performing and to compare different hardware platforms. If they are available to you, standardized benchmarks are also a good way to analyze the performance of your particular platform (refer to Chapter 5, “Benchmarking”).

Using a standardized benchmark such as the TPC-C benchmark is not a good way to tune your system. Each system should be tuned individually based on its own characteristics. A system that has been tuned for a benchmark, such as TPC-C, can provide useful tuning hints. Because the primary goal of a TPC benchmark is for the sponsor to get the best possible performance, you can see how the sponsors have optimally tuned the system.

Because an official TPC-C benchmark that uses Oracle is usually submitted by the hardware vendor, OS vendor, and Oracle, you can be assured that the system has been tuned as optimally as possible. If you get the chance, try to obtain a Full Disclosure Report from the TPC (on the Web at http://www.tpc.org) and look at the way the system was designed and tuned.

Of course, the best benchmark for your system is one designed and built to run your application. This benchmark provides you with all the information you need to judge the amount and size of the hardware required. Your custom benchmark will also provide you with valuable information about any configuration changes you make.

The design and function of your benchmark is based entirely on your application and system configuration. Try to create a benchmark that has a variable load so that you can push the system to its limits to gather maximum load information.

Summary

OLTP systems are probably the most common RDBMS systems in use today. As such, a wealth of tuning knowledge is available. This chapter examined the following characteristics of the OLTP system:

  Significant numbers of user processes. OLTP systems usually support hundreds or thousands of users.
  Heavy I/O usage. Each user concurrently accesses many different tables with both read and update activity, causing many concurrent I/Os on the system.
  A strict response time criteria. Strict response times are characteristic of the OLTP system. The OLTP system supports online users, and online users demand reasonable response times. Each second the user waits may cost the company money.
  A strict uptime criteria. In most OLTP configurations, downtime is not an option. The system may have to be up 24 hours a day, 7 days a week.

This chapter analyzed the characteristics of the system and analyzed the data access patterns typically involved with the OLTP system. The chapter then looked at some of the ways the system can be optimally designed and tuned. You also learned about some enhancements you can make to the RDBMS, OS, and hardware to improve system performance (you also learned about some enhancements that don’t help). The last section of the chapter examined the verification methods you can use to confirm that your tuning efforts have positively affected the performance of the system.

The next chapters look at some of the other classes of systems with which Oracle is used, including decision support systems, batch processing systems, and others.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.